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[57] ABSTRACT 

A component server architecture is provided that enables 
consumer nodes of a computer network to interact with 
heterogeneous software components and services distributed 
throughout the network, as well as network devices and data. 
Distributed interaction between a consumer and heteroge- 
neous software is achieved, in part, by registering and 
locating the components and services (hereafter referred to 
collectively as components). An objea-neulral global com- 
ponent registry with access controls of the architecture 
interoperates with a component management service (CMS) 
to transparently ensure proper administration, authentication 
and run-time binding access to components offered in 
response to requests from applications executing on the 
consumer nodes. The architecture is implemented on a 
component server node of the network that is configured to 
communicate with the consumer, i.e., client, nodes in client- 
server computing arrangements. That is, the component 
registry of the component server node responds to a con- 
sumer application request by locating a heterogeneous com- 
ponent for the consumer. The registry offers this component 
to the consumer by providing an appropriate interface 
between the object model of the consumer and the object 
model of the software component. This registry is preferably 
organized as a plurality of cooperating storage entities 
including a description repository, an offer repository, an 
interface adapter repository and an object factory repository. 

31 Claims, 9 Drawing Sheets 
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NETWORK COMPONENT SERVER 

CROSS-REFERENCE TO RELATED 
APPLICAnONS 

This invention is related to co-pending U.S. patent appli- S 
cation Scr. No. 08/576,647. entitled: Method for Managing 
Globally Distributed Software Components, filed Dec. 21, 
1995. 

HELD OF THE INVENTION 
This invention relates generally to computer networks and 
a system for managing and integrating distributed compo- 
nents which reside on the network. More particularly this 
invention is directed to a method for locating, registering, 
and interoperating with heterogeneous network components 15 
comprising software objects and services, hardware devices, 
and data which reside on and execute in a local or wide area 
network. 

BACKGROUND OF THE INVENTION 

20 

Modem information technology provides a vast array of 
software to meet many different needs. However, after a 
need is identified, the shear volume of available technology 
and the lack of common architectures make generation and 
management of custom solutions diflScult and expensive. ^5 
Component software encourages encapsulation and reuse of 
software routines for decreasing program development and 
maintenance time. Distributed software systems allow soft- 
ware services, components, and objects to work together 
over network infrastructures such as Local Area Networks 30 
(LAN), Wide Area Networks (WAN), and the Internet. The 
current software world is littered with existing software 
systems, heterogeneous hardware platforms and heteroge- 
neous software object models which all contribute to the 
complexity of distributed software systems. 35 

Software systems which utilize distributed components 
first require a method to locate services or components on 
the network. Hardcoding addresses, configuration files, 
command line parameters, service broadcasting, naming 
systems, local or distributed repositories are all known 40 
methods that are used to locate services and components on 
the network. A summary of the more common of these 
conventional locating methods follows. 

Hie Component Object Model (COM) method for locat- 
ing components utilizes a registry file with a specific format. 45 
Non-COM software components carmot be stored in the 
COM registry. Object Linking and Embedding (OLE)/COM 
/ActiveX software components are accessible on a given 
computer only if they are registered in a local registry file. 
The COM registry file maps software component identifiers so 
known as class identifiers (CLSIDs) to the file system 
location of a binary object and to type library information 
about the interfaoe(s) of the server component. This provides 
a framework to make individual pieces of software 
available, but it is limited to COM objects and to the 55 
software that can access the local registry file. 

This reliance on the local registry file unduly limits 
component availability and creates scaling problems if many 
computers need access to the registration information. While 
COM components may be stored on computers that arc 60 
connected to a LAN and clients of these components may 
also reside on the LAN, COM does not take full advantage 
of the capabilities of LAN administration tools. Most often 
COM assumes its environment will be a single isolated 
computer. The COM object model enables COM compo- 65 
nents to interact, but does very little to enable component 
distribution. 



2 

Distributed COM (DCOM) adds remote execution and 
distributed naming to COM. DCOM locates components 
using the same mechanisms defined in COM (the location 
can be supplied by the client in a local Windows registry). 
In addition DCOM plans to use the NT 5.0 active directory 
where references to objects arc distributed with the naming 
system. Once DCOM has located a component on the 
network it issues a remote procedure call to the destination 
system to access remote objects. DCOM improves upon 
COM, but DCOM still has limitations in the area of inter- 
operation with heterogeneous object models, and in the use 
of common LAN administration tools. 

Java applets and programs provide another architecture 
for locating distributed software components. Java applets 
are miniature programs that are executed while users view 
Internet information, such as World-Wide-Web pages. Java 
applets are linked or included in World-Wide-Web pages in 
a similar manner as images or other data with hard-coded 
references to an Interact HTTP address. When a user selects 
a highlighted or underiined portion of a web page that was 
linked to the Java applet, the Java applet is transfened across 
the Internet to the user's Web browser where the Java applet 
is executed. If the browser contains a Java interpreter, the 
Java applet (comprising Java byte codes) is loaded and 
executed by a Java Virtual Machine (JVM) embedded within 
the web browser. 

The Java architecture is an improvement over the archi- 
tecture for the COM model because in addition to the 
reference and interfaces, the software is also distributed 
dynamically. Components are hardware independent. 
However, the link or reference to a Java applet (class) across 
the Internet is a static physical reference at one moment in 
time. If the Java applet is moved, the web page cannot find 
it. In addition, Java applets and COM objects do not work 
together without custom written browsers and static object 
wrappers which perform the necessary interface transforma- 
tions or adaptations. 

Also, a Remote Metiiod Invocation (RMT) architecture is 
included in the Java architecture which allows remoting 
between Java objects and remote execution of applets, thus 
creating a distributed object system. TTie RMI architecture 
includes a bootstrap registry which is used to locate distrib- 
uted Java components. Although similar in concept to the 
local COM registry, the RMI bootstrap registry does not 
interoperate with objects other than Java objects and cannot 
store information about components for different object 
models as was the case for the local COM registry. Neither 
registry is fully scaleable or distributed across the network, 
and therefore objects cannot be managed as part of the object 
distribution system. 

Another method for component discovery periodically 
broadcasts or advertises services across the network. One 
implemenution of this is User Datagram Protocol (UDP) 
broadcasts in the TCP/IP protocol, while another implemen- 
tation of this method is Novell's Service Advertisement 
Protocol (SAP). SAP provides a means for independently 
locating components (i.e., hard-coding of service location is 
no longer needed). However, this method consumes a sig- 
nificant amoiml of network bandwidth and is therefore an 
undesirable solution to locate components in a global net- 
work. 

The Common Object Request Broker Architecture 
(CORBA) defines additional ways to locate components. At 
its most basic level, CORBA provides an implementation 
repository (similar to the RMI bootstrap registry or tiie COM 
local Windows registry); in addition, CORBA defines a 
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binding service, an interface repository and optional naming control. This problem becomes even more significant as the 

and trading services. The trading service maintains a reposi- network grows in size. 

tory of object types and offers. The interface repository for example, system administrators require the ability to 

CORBA is a runtime database containing interface definition control naming of components so that they can be efficiently 

language (IDL)-dcfined interfaces, where IDL is the stan- s located and accessed anywhere on a global network. It is 

in CORRAfor specifying the interfaces undesirable for administrators and en-dusers to physically 

of CORBA objects. Operationally, a provider of a new ^ components at every node on the net- 

service on Oie network registers mformation about the new component programmers are reluctant to pro- 

service with the implementation repository either directly or ' ^ *^ ^ * -^l * j * c 

. J. ,1 . . J • 1 vide access to software components without adequate satc- 

mdircctly via a naming service or Trader service. Thereafter, j . . . *u • j r»u • „ in. 

1- . ^1 ■ 1 . ■ iruards that protect unauthorized use of their software. These 

a chent on the network accesses the implementation reposi- ? . . •« . j . .i. j i • r. n . c 

~ * i„ L • 1 issues have contnbuted to the delay m full acceptance or 

tory either directly (staUc reference to known physical j. * u * -a * f*, « 

^ ' . u-u *- distnbuted component software, 
objects), or via naming or tradmg services which contam a 

logical representation of the CORBAobjecU that are avafl- The Pfe^en' mvenUon addresses these issues and in 

able CD the network at any point in time. The naming and „ particular, is directed to a component server architecture that 

trading services cross the boundary from physical object provides an infrastructure for administenng, mtegratmg. 

references to logical object references. This is an improve- exposing and managing distnbuted heterogeneous compo- 

ment over the COM and Java models for object location. "en's *°<1 services. More qiecifically. the present mvention 

SpeciftcaUy, the Trader service assures that the types and ^ '°.'«' ^^^^^'^ that facilitates discovery of, 

interfaces of the provided service matches the service access to and mteroperaUon among various components and 

, J . rr. J ^ software in a distnbuted system, 

requested by accessing the Trader type repository. The ^ « * jr 

Trader obtains an object reference to the service offer from Therefore, it is an object of the present invention to 

the trader offer repository which indexes the CORBA imple- provide a system for managing the location, distribution and 

mentation repository. The object reference to the scivicc access of various software, hardware, and data components 

offer is then passed back to the client so that the software ^ and component object models distnbuted m a computer 

objects can bind via the CORBA binding service. network. 

The CORBA object model requires that CORBA be the Another object of the invenUon is to provide a component 

design center for distributed systems and that all other object management system which internally supports various 

models must bridge to it. The CORBA object model object modeUng systems for integration within a directory 

addresses the need for interoperation between object models 30 services provider. 

by requiring all non-CORBA objects to wear CORBA It is yet another object of the present invention to provide 

wrappers, or "jackets". To a CORBAsystem, all objects may such a system which takes advantage of the capabilities of 

interoperatc as long as they "look" like CORBA objects. Internet servers. 

Accordingly, CORBA addresses problems associated with , ^^^^r 

scaleabiufy; location independence, and interopcrabiUty, by 35 SUMMARY OF THE INVENTION 

providing implementation repositories, interface The invention comprises a network component server 

repositories, and naming/trader services. However, in architecture that manages and enables consumer nodes of a 

CORBA all objects must bridge to CORBA, and CORBA computer network to interact with hetcrogcneoiis software 

does not take fiill advantage of the abilities of LAN admin- components, hardware devices, data objects and services 

istration tools. 40 distributed throughout the network, as well as network 

These conventional methods generally use different stan- devices and data. Distributed management and interaction 

dards to create a single software component model and between a consumer and heterogeneous objects are 

architecture (both hardware and software) known to work achieved, in part, by registering and locating the software 

together. Yet, these standards do not allow management and components, hardware devices, data objects and services 

integration of heterogeneous components. While integration 45 (hereafter referred to collectively as components). Accord- 

among and changes to existing systems require significant ing to the present invention, a novel object neutral, global 

re-engineering, the flexibility to adopt new technologies component registry with security access control of the 

wanes as these systems become more complex. This results architecture interoperates with a component management 

in conventional systems being "locked into" hardware, service (CMS) to transparently ensure proper 

programming languages, software object models and distri- 50 administration, authentication and run-time binding access 

bution frameworks for well-known components and systems to components offered in response to requests from appU- 

having controlled interactions. Within each system, object cations executing on the consumer nodes, 

distribution, discovery, binding and management follow In the illustrative embodiment, the inventive architecture 

models that are tightly -coup led with a defined object model. is implemented on a component server node of the network 

Heterogeneity among such different known systems thus 55 that is configured to communicate with the consumer, i.e., 

requires bridges and custom interfaces. client, nodes in client-server computing arrangements. That 

In summary, conventional component object models is, the component registry CMS of the network component 

define their own independent object-model centric registries server node responds to a consumer application request by 

and repositories for locating distributed software objects. locating a heterogeneous component for the consumer; 

These registries arc not integrated within object models, and 6Q according to an aspect of the present invention, the global 

they are limited to software objects. Currently, there is no component registry offers this component to the consumer 

object neutral global component registry with security by providing an appropriate interface between the object 

access control. Also there is no component services registry model of the consumer and the object model of the software 

having a common point of management for distributed component. The novel registry is preferably organized as a 

components that enable interoperability among these inde- 65 plurality of cooperating storage entities including a descrip- 

pendent registries. Moreover, management of components in tion repository, an offer repository, an interface adapter 

a network is problematic because there is no single point of repository and an object factory repository. 
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Specifically, the description repository includes similar 
functionality to the CORBA trader service type repository 
along with the additional functionality of object model 
neutrality, access controls, and an overall integration with all 
repositories to form a compoowit registry. The offer reposi- 
tory comprises the functionality contained in the CORBA 
offer repository, the CORBA implementation repository, the 
Windows registry, the Java bootstrap registry, in addition to 
object model neutrality and access controls. The interface 
adapter repository is a superset of the functionality com- 
prised in the CORBA interface repository, and the COM 
type libraries. The object factory repository contains imple- 
mentations of components which can be utilized in object 
instantiation. 

The CMS performs an initial look-up function in the 
description repository to determine whether the requested 
component is registered with the component registry. The 
description repository acts as a template describing the set of 
like components. If the description is found, the request is 
routed by the CMS to the offer repository where references 
to specific instances of that component type are registered. 
Here the registered component instances are examined to 
determine whether they match the requested component 
properties. If the instances match, the component reference 
is passed by the CMS to the requesting component con- 
sumer. If the offer repository does not contain the desired 
component, CMS looks in the object factory repository for 
implementations of the required component If an imple- 
mentation of the component exists the component is instan- 
tiated and its reference is passed back to the component 
consumer. If the new component is not implemented in the 
object model expected by the component consumer, CMS 
utilizes the interface adapter repository to manufacture an 
interface between the object model of the component 
consumer, and the component's implementation. 

Operationally, the CMS selects an appropriate interface 
specification from the interface adapter repository for imple- 
menting the offered component and passes that interface to 
the CMS. The CMS then provides the binding needed to 
establish communication between the offered component 
and requesting application. If different object models are 
used for these communicating elements, the CMS invokes 
an interface adapter to transform the offered component 
model to that of the requesting application. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The above and further advantages of the invention may be 
better understood by referring to the following description in 
conjunction with the accompanying drawings in which like 
reference numbers indicate identical or functionally similar 
elements: 

FIG. 1 is an illustration of a network environment for the 
system used in an embodiment of the present invention; 

FIG. 2 is a data flow diagram for a system architecture 
according to an embodiment of the present invention; 

FIG. 3 illustrates component model redirection according 
to an embodiment of the present invention; 

FIGS. 4A and 4B illustrate a component registry imple- 
mented according to an embodiment of the present inven- 
tion; 

FIG. 5 illustrates a component instantiation according to 
an embodiment of the present invention; 

FIG. 6 illustrates component object model bridging 
according to an embodiment of the present invention; 

no. 7 illustrates authentication of components by the 
CMS according to an embodiment of the present invention; 
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FIGS. SAand 8B ilhistrate the administration of the CMS 
according to an embodiment of the present invention; and 

FIG, 9 illustrates the distribution and replication of com- 
ponents by the CMS according to an embodiment of the 
5 invention. 

DETAILED DESCRIPTION OF THE 
INVENTION 

FIG. 1 is a block diagram of a computer network envi- 
ronment 100 comprising a collection of commimication 
links and subnetworks 104, 106, 108, 110 and 120 connected 
to a plurality of nodes that may be advantageously used with 
the component server architecture of the present invention. 
The nodes are typically computers such as local and/or 
remote mobile systems embodied as personal computers 
(PC), laptops, workstations, mainframes, minicomputers, 
network computers (NC), personal digital assistants (PDA), 
Java Stations, file servers and/or application servers and 
network devices. Communication among the nodes is typi- 
cally effected by exchanging discrete data packets or frames 
over network signal lines such as twisted pair, coaxial, 
optical fiber, telephone lines, satellites, microwave, relays, 
modulated AC powerlines, infrared wireless, or other con- 

^ ventionally known data transmission systems. 

Each node generally comprises a plurality of intercon- 
nected elements, such as a processor 112, a memory 114 and 
an input/output (I/O) adapter 116. The memory 114 may 
comprise storage locations addressable by the processor 112 

3Q and I/O adapter 116 for storing software application pro- 
grams and component data structures associated with the 
inventive architecture described herein. In addition, the 
processor 112 may comprise processing elements or logic 
for executing the application programs and manipulating the 

35 software components according to the techniques described 
herein. An operating system, portions of which are typically 
resident in memory and executed by the processor, func- 
tionally organizes the node by, inter alia, invoking network 
operations in support of software processes executing on the 
node. It wiU be apparent to those skilled in the art that other 
processor and memory means, including various computer 
readable media, may be used for storing and executing 
program instructions pertaining to the described techniques. 
The subnetworks may include local area networks 

45 (LANs), such as Intranets, and wide area networks (WANs) 
Unks, including the Internet. The computer network envi- 
ronment may be configured as a single LAN or multiple 
permutations of LANs, WANs and the Internet intercon- 
nected by hubs, routers, bridges and/or gateways, as appre- 

50 ciated by those skilled in the art. Network protocols execut- 
ing over the network environment may include IPX/SPX, 
TCP/IP, AppleTalk and Internet Inter-ORB protocol (IIOP), 
whereas network operating systems controlling the com- 
puter network may include Novell NetWare Version 4.x, 

55 VINES, Windows NT and LAN Manager and LANtastic 
NetWork and UNIX. 

The component server architecture of the present inven- 
tion may be configured to reside on any node having 
sufficient data storage, network connectivity and processing 

60 capability. In the illustrative embodiment, however, the 
architecture is preferably implemented on a component 
server node configured to provide services in response to 
requests from applications executing on client, i.e., 
consumer, nodes of the network. The component server may 

65 comprise a single instance or multiple instantiations config- 
ured to operate collectively or independently on a node, 
while the consumers may reside on any node in the network 
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including the same node as the component server. These such as ORACLE or SYBASE, flat file databases or memory 

consumer nodes may include non-traditional network nodes resident repositories. 

such as embedded software devices, hardware devices, Component requests to the network component server 

printers, routers, modems, databases, database objects, may be redirected to the CMS 280 via paths 5 and 22 or 

stored procedures and network-accessible data and hard- 5 called directly via paths 3 and 23. Both types of requests are 

ware. handled similarly by the CMS 280. Specifically, the CMS 

Network Component Server Architecture 280 first checks the component registry 250 (via paths 9 and 

According to the invention, the component server archi- 10) to determine if the requested component is available in 

tecture described herein provides a framework for enabling the offer repository 254. If the component is available, 

distributed interaction between a consumer application and lO binding information is returned to the requesting consumer 

heterogeneous software components and services. That is, application 210 via paths 22 or 23. If the component is not 

the architectural framework enables advertisement and available, the request is forwarded to the object factory 240 

transparent location of components and services (hereinafter via path 11 to activate an object corresponding to the 

referred to collectively as components), along with requested component. 

authentication, distribution, administration and run-time 15 In response to the request, the object factory 240 checks 

binding of those components to consumers. FIG. 2 is a the object factory repository 252 (via paths 12 and 13) to 

schematic block diagram showing the interaction between determine if the requested component implementation 

an application 210 executing on a consumer node and exists. If so, the object factory 240 "starts" the requested 

various elements of the architecture 200 including a native component as described with reference to FIG, 5. If 

component object (NCO) model 220, a network components 20 .successful, the object factory 240 registers a new instantia- 

and services (NCS) 230, an object factory 240, a component tion of the requested component with the offer repository 

registry 250, a component administration (CA) application 254 via path 14. The object factory 240 returns a newly 

260, an interface adapter 270 and a component management registered offer reference for the requested component to the 

service (CMS) 280. CMS 280 via path 15. Or alternatively, the requested com- 

The consumer application 210 may include a stand-alone is ponent registers itself via path 21. In either case the object 

application and applet that requests components for execu- factory 240 returns a newly registered offer reference for the 

tion either locally or remotely, the latter via conventional' requested component to the CMS 280 via path 15. 

remoting technology such as remote procedure calls (RPCs) At this point, CMS 280 determines whether the offer 

and RMI, i.e,, proxy/skeleton interaction. As indicated by reference obtained from the object factory 240 (via paths 11 

path 1, the consumer application may be started by an 30 and 15) or from the offer repository 254 (via paths 9 and 10) 

end -user, administrator or other component. Requests for matches the object model requested by the consumer appH- 

components may be issued by the application to the NCO cation 210 (via paths 3 and 5). If the object models of the 

model 220 via path 2 or directly to the CMS 280 via path 3. offer or implementation match the NCO model 220 of the 

These latter direct requests allow the application to take full requesting application, the object reference is returned via 

advantage of CMS features such as run-time discovery, 35 paths 22 and 23; otherwise, the interface adapter repository 

dynamic authentication and binding to network components. 270 is used to bridge the object models via paths 16 and 19, 

If the application 210 is an existing or "Network Com- as described further with reference to FIG. 6. Briefly, the 

ponent Server-unaware" application, then components are interface adapter 270 sends a request to the interface adapter 

preferably accessed via the NCO model 220 which allows repository 256 (over paths 17 and 18 of CMS 280) to build 

backward compatibility through bind services with the NCS 40 an appropriate interface between the offered component and 

230. These applications may utilize the CMS 280 transpar- the object model of the requesting application. As a result, 

ently through object model redirection (indicated by paths 5, an offer is reOimed to the requesting application (via paths 

22 and 8) as discussed further in cormection with FIG. 3, 22 and 23) that resembles a native component, 

although requests received by the NCO model 220 (via path The CA application 260 uses an interface provided via 

2) need not be redirected to take advantage of the CMS 280. 45 path 24 to configure the CMS 280 and to manage informa- 

Applications that bind natively to NCS 230 through paths 4, tion stored in the component registry 250. The registry 250 

7 and 8 use the native component registry of the NCO model may further be administered by native administration pro- 

220 for an appropriate object-model. These native services grams associated with the architecture and used to imple- 

may be started, installed and managed manually via path 6, ment the registry (via path 25). For example in the illustra- 

or they may be instantiated and managed by CMS 280 via so live embodiment based on NDS, NWAdmin (i.e., a program 

path 20, Object binding with the native registry can also be used to administer NDS) may be utilized to administer the 

administered indirectly in the component registry 250 and component registry 250, Administration of components will 

"pushed-out" (or distributed) to native registries through be discussed in more detail with reference to FIG, 7. 

paths 10 and 22. Native Object Model Redirection 

The component registry 250 interoperates with the CMS 55 The component server architecture provides redirection 

280 to, inter alia, determine how to bind the requesting processes that allow existing components to interact with the 

application with an appropriate component. The component CMS without requiring rewrite of the components* software, 

registry 250 may be implemented on any persistent storage Moreover, these processes enable software developers to 

mechanism and preferably comprises an object factory write components to a single familiar object model using 

repository 252, an offer repository 254, an interface adapter 60 familiar tools, programming languages and interfaces that 

repository 256 and a description repository 258. In the require little or no knowledge of the component server, 

illustrative embodiment, the component registry 250 is Through redirection, legacy applications can be exposed as 

based upon NetWare directory services (NDS) although components and managed transparently, 

other directory service technology may be used to supply Native object model redirection is preferably accom- 

such a global component registry infrastructure; examples of 65 plished in two ways: (i) through interception of and adding 

these alternative technologies include LDAP or X.500 com- functionality to existing programming interfaces, and (ii) 

pliant naming systems, ODBC/JDBC compliant databases through populating or redistributing information from the 
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component registry to native object model registries. Global Component Registry 

Examples of redirected component models include COM, In accordance with the inventive architecture described 

Java RMI and CORBA. FIG. 3 illustrates redirection of herein, the global component registry inleroperates with the 

native component object models to the CMS for an cmbodi- CMS to transparently ensure proper administration, authcn- 

ment of the present invention including the COM, Java RMI 5 licalion and run-time binding access to components offered 

and CORBA component models. in response to requests from applications executing on the 

COM applications 310 typically request component infor- consumer nodes. FIG. 4 A is a block diagram of the com- 

mation from a Windows registry 312 by issuing COM ponent registry. In a preferred embodiment of the invention, 

application programming interface (API) function calls, the component registry 400 is implemented using NDS, 

such as CoCreatelnslance and CoGetClassObjecl, via path 1 . lO although alternative embodiments may utilize other naming 

In response to these COM functions, the Windows registry systems (e.g., COS Naming, X.500 directories, LDAP, XFN, 

312 loads the requested component locally or remotely binds Cairo), databases (e.g., ODBC/JDBC compliant, SQL. 

to the requested COM object via path 2. In accordance with ORACLE, SYBASE), flat files and memory resident reposi- 

the invention, the CMS 340 "redirects" the COM object tones that, in general, do not offer the range of fiinctionality 

model by intercepting the CoCreatelnstance and CoGetClas- 15 provided by NDS. 

sObject function calls (path 3), and thereafter passing que- The component registry 400 is the single point of infor- 

ries to the component registry over path 15 rather than to the mation for routing of all software component requests from 

local Windows registry 312. CMS 340 and the component consumers of the network. According to an aspect of the 

registry 350 then cooperate to bind the request to the present invention, the registry 400 is used by CMS to 

required component. 20 respond to such requests by offering components through 

Similarly, Java objects 324 and CORBA objects 334 are appropriate interfaces between the object models of the 

accessible to the COM applications 310 via the CMS 340. consumers and of the software components. To that end, the 

Specifically, CMS 340 intercepts the COM API calls by novel global registry is preferably organized as a plurality of 

replacing OLE32.DLL (contained in the Windows system cooperating storage entities including a description 

folder) with a "CMS-aware" DLL that provides new entry 25 repository, an offer repository, an interface adapter reposi- 

points for the CoCreate Instance and CoGetCIassObject tory and an object factory repository, 

calls. Entry points for other COM calls are passed through The description repository 410 ensures consistent 

to the OLE32.DLL. CMS 340 is preferably used in the COM interfaces, properties, versions and implementations 

model to store and downbad DLLs, store file-map refer- between components so that all instances of a component 

ences to components and store components as binaries in the 30 type are guaranteed to share the same characteristics. The 

component registry 350 with location transparency. description repository 410 essentially functions as an initial 

Java applications 320 that request loading of additional look up to determine whether the type of the requested 
Java classes or applets (via path 5) typically employ a Java component is part of, i.e., registered with, the description 
class loader to locate (either locally or via static HTTP web repository 410. If the type of the requested component is 
addresses) the required Java component objects 324 from a 35 found in this repository 410, the request is directed to the 
bootstrap Java RMI registry 322. The Java application offer repository 420 where specific instances of that corn- 
request may be re-directed to the component registry 350 by ponent type are registered. Here, the registered component 
extending the Java class loader to access the CMS 340 (via instances are examined to determine whether they match the 
path 7) for binding to the requested object component (via requested component and, if so, the object factory repository 
path 8). COM objects 314 and CORBA objects 334 are 4o 430 is accessed. 

likewise accessible to the Java applications 320 via CMS However, if the type of the requested component is not 

340 over paths 4 and 13. As with the COM model, CMS 340 found in the description repository 410. an indication will be 

is used in the Java model to store and download Java Classes issued to the user that no components exist which corre- 

and applets, store file-map and HTTP references to compo- spond to the requested component. Also, if the requested 

nents and to store components as binaries in the component 45 component does not match any of the component instances, 

registry with location transparency. the object factory (as discussed in connection with FIG. 2) 

CORBA applications 330 typically request CORBA is accessed to register the offer reference for the requested 

objects 334 by way of a CORBA registry (or Trader service) component. 

332 (via paths 9 and 10). To take advantage of global The object factory repository 430 is a persistent storage of 

management capabilities, requests from the CORBA appli- 50 implementations for the components registered in the offer 

cations 330 may be redirected to the CMS 340 via path 12. repository; this repository provides the specific object imple- 

Standard CORBA bind methods can be extended by redi- mentation for the offered component. Finally, the appropri- 
rection to the CMS 340 to locate the requested CORBA ate interface is invoked from the interface adapter repository 

objects 334. Moreover, Java objects 324 and COM objects 440 to allow communication between the requesting appli- 

314 are accessible to CORBA applications 330 via CMS 340 ss cation and component object implementation. The interface 

over paths 4 and 8. adapter repository 440 is a superset of interface specifica- 

The second method for redirection of native component tions for desired object models which describe a means for 

models involves management of component information in accessing the offered component 

the CMS 340 and redistribution of this information to native It is noted that the description repository 410 is logically 

object model registries (such as the Windows registry 312, 60 part of the component registry 400, but may be physically 

the Java registry 322 and the CORBA registry 332). This separate from the offer repository 420, object factory reposi- 

method of redirection allows administrators to install com- tory 430 and the interface adapter repository 440 so that 
ponents only once and "push" them out to local registries for multiple CMS servers may share common component defi- 
consumption by native object models. ITiis method also nitions. Separation of the description repository 410 from 

allows caching of components from a central implementa- 65 the other repositories of the component registry 400 also 

tion repository (such as the component registry 350) to local allows application of "thick grained", one-step administra- 

repositories for mobile computing. tion functions. In the preferred embodiment, administration 
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functions such as access control list manipulation can be to the local proxy object via path 4 after the component 

applied to a given component type in the description reposi- registry 520 provides the appropriate component to the 

tory 410 and then the operation may be replicated by NDS requested application via path 2. 

to all interfaces, offers and implementations of the compo- The CMS 510 also may speed system through-put by 
nent type in the entire network. 5 caching components. This caching may involve serialization 
The physical implementation of the component registry of components out to disk to save state and restore when 
400 is preferably accomplished by modi^ing the NDS needed. For instance, just-in-time (JIT) compiled Java byte- 
schema to define attributes and relationships between codes are saved for future requests for a specific Java class, 
objects in NDS. The NDS schema may be further modified Dynamically generated component interfaces (via interface 
to allow representation of multiple component servers and lo bridging) are saved for future references. The CMS 510 can 
type repositories at any node in the NDS tree. In the also be used to cache network components to a local storage 
illustrative embodiment, three additional NDS container to aid in mobile computing where the network is used lo 
objects and four new NDS leaf objects are added to the NDS down-load applications, and components when the network 
schema as illustrated in FTG. 4B. The container objects connection is available. When the network connection goes 
include a description repository container 450, a component 15 away, the cached or down-loaded components are available 
server container 460 and a description container 470, for execution. 

whereas the leaf objects include type objects 452, offer Load balancing is also accomplished by the CMS 510. As 

objects 472, implementation objects 474 and interface requests for services are received, real-time decisions can be 

objects 476. made and administrative policies can be enforced to limit the 

The description repository containers 450 only contain 20 number of connections to given services, and to maximize 

type objects 452. The type objects 452 define required CMS utilization of the CPU. Multiple hardware servers can be 

properties of any offers of the named type. Additional populated with services as requests are received, 

attributes and properties may be added to the CMS type If services are started on a remote machine, the capability 

objects and the description repository container 450 to to spawn processes on a given remote machine is required, 

specify configuration information and persistent data for the 25 Some operating systems such as NetWare allow remote 

description repository 410. The component server containers start-up of executables. Other systems require a resident 

460 hold a desired number of the description type containers application on the remote machine (such as the inet daemon 

470 which aid in the administration, look-up and organiza- on Unix) which listens for requests and actually starts 

tioD of implementations and offers. The component server applications as requested, 

containers 460 also have additional attributes and properties 30 Component Object Model Bridging 

to specify configuration information and persistent data for The present invention further provides information in a 

the named component server. global component registry to enable interface bridging 

The description type containers 470 have NDS associa- between different component object models. The CMS infra- 

tions with actual type objects in the description repository structure provides information to enable static object model 

410. The description type containers 470 may contain any 35 bridging, where hard-coded (program implementation time) 

combination of other description containers, offer objects interfaces or wrapper code is part of the component imple- 

472, implementation objects 474, and interface objects 476. mentation. Dynamic generation of object bridges requires 

NDS access controls (by an individual user or by a group) that a super-set of interface information be stored in the 

may be set on individual and combinations of objects and interface adapter repository of the component registry. This 

containers for the schema of the component registry 400. 40 information includes IDL definitions in the case of CORE A, 

The component server objects added to the NDS Schema unknown interface information in the case of OLE/COM 
and added to the NDS tree inherit all of the functionality and an intermediate object-neutral interface representation 
implemented in NDS and the NDS administration applica- to enable other object model bridging, 
tions because they are all "first-class" NDS objects. NDS In FIG. 6, an embodiment of the present invention is 
features that add value to the CMS include: replication, 45 illustrated for an application 600 that makes a request to the 
security, single sign-on authentication, access control lists, CMS 610 for a service or a remote object 630 via path 1. The 
licensing and scaleabihty. Alternative embodiments of the component registry 620 then provides the appropriate com- 
invention where the component registry 400 is not based ponent to the requested application via path 2. If a static 
upon NDS are limited in functionaUty in direct proportion to wrapper implementation exists for the object model of the 
the availability of these NDS features. FIG. 4B contains one 50 application, a static proxy code is supplied to the applica- 
of many possible schema layout implementations and the tion. The proxy code generates a wrapper object 608 for 
present invention is not limited to the layout shown in this providing a one-to-one bridge via path 3 that is both trans- 
figure, parent to the consuming application and is created statically 
Component Instantiation at component design time. If no object model bridge exists. 

In accordance with the present invention, the instantiation 5S the CMS 610 uses information in the interface adapter 

of components in a distributed network is aided by the repository of the component registry 620 to build proxy code 

interaction between the inventive CMS and component which binds with the remote object or service 630. This 

registry. As illustrated in FIG. 5, an application 500 sends a method is slower than the object-wrapper approach, but it is 

request for a component lo the CMS 510 via path 1. The more flexible in that it provides various object bridges (i.e., 

component management system supports both local and 60 bridging from many object -models to many-object models), 

remote instantiation of components. Local instantiation 502 For simple and common data types, a dynamic proxy 

involves downloading and execution of the actual compo- generated by the CMS 610 may use type casting 604 to 

nent on the same platform as the application whether in the directly map data types between object systems via path 4. 

same process, a separate thread, or a separate process. For more complex data types, the dynamic proxy generated 

Remote instantiation 504 involves loading a proxy object on 65 by the CMS 610 may require a two step transfonnation from 
the local machine, starting the service on a remote node of the native object type, to an object-neutral intermediate 

the network 530 via path 3, and binding the remote service representation 602, and then to the desired object system 
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representalion via path 5. This method pays more perfor- 
mance penalty, but is more flexible in that only one object 
model mapping Ls required for each object system to the 
intermediate representation and that the method is 
bi-directional. The interface adapting capabilities of the 
CMS 610 then can bridge between any object model which 
bridges to the intermediate representation. 
Component Authentication 

An important feature provided for distributed object sys- 
tem in accordance with the CMS of the present invention is 
the capability to associate access control information with 
components in the distributed network. The inventive CMS 
allows control over who owns interfaces, implementations, 
and offers, as well as who has the right to find, use or modify 
those objects. This capability is an enabling feature for 
allowing fine-grained control over the distribution, 
maintenance, versioning, licensing, metering, 
administration, and access to globally-distributed software. 

In the preferred embodiment, an NDS identity can be used 
to associate any operation with a user because the CMS is 
used as the look-up and binding point of control. Stated 
another way, the CMS uses NDS to provide user authenti- 
cation and client identity. The CMS can control who pro- 
vides components and services by specifying who can add to 
the object factory and offer repositories of the component 
registry. The CMS can control which users or groups of 
users have access to see components, and who has the 
privilege or license to use the components. The CMS also 
controls when the binding operation begins and identifies the 
component or service consumer. As a result, a software 
metering capability may be enabled to license software 
components on a per-use basis. 

FIG. 7 illustrates a component authentication according to 
an embodiment of the present invention where an applica- 
tion 700 which has an application identity established during 
a login operation via path 1. The CMS 710 has a CMS 
identity 712 which is established during initiation of the 
CMS via path 2. A remote service 730 has an associated 
identity obtained either during the manual start-up of the 
service via path 3 or that is inherited from the CMS 710 via 
path 4 when the service is started. Access controls are set in 
the component registry 720 via path 5 by standard NDS 
administration utilities. These identities are utilized through- 
out the start-up, registration, lookup, and binding operations. 
When the CMS 710 is initiated, it must have the proper CMS 
ID 712 to access the component repository 720. Services- 
must have the proper ID in order to register and advertise 
themselves through the CMS 720. Applications must have 
the proper AppID 702 to lookup offers in the CMS 710 via 
path 6, and to request binding to the offers of the remote 
service 730 via path 8. The management of these access 
controls and the authenticated IDs of the CMS 710 are all 
provided by the component registry 720 via path 7 which 
uses NDS for these features in the preferred embodiment. 

Alternative embodiments of the present invention may be 
utilized where the implementation of the component registry 
720 relies upon technology other than NDS to provide 
authentication and access control. 
Component Administration 

The present invention further provides unique and novel 
component administration capabilities. In particular, as illus- 
trated in FIG. 8A, interfaces between CA applications 880 
and a description repository 810 via path 1, an interface 
adapter repository 840 via path 2, an offer repository 820 via 
path 3, and an object factory repository 830 via path 4 of a 
component registry 800 are provided. In a preferred 
embodiment, NDS administration applications and NDS 
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Access controls are utilized so that an administrator has fine 
grained (down to the individual user and individual offer) 
access control over individual components. The administra- 
tor also has wide-grained control of the system, (up to 
operations on whole types of components, complete groups 
and organizatbns, and complete Component Management 
Servers). 

As illustrated in FIG. 8 B, administrators can browse the 
component server tree 860 for description type containers 
870, and associated offer components 872, implementation 
components 874, and interface components 876 of the 
description type containers 870. Also, administrators can 
browse description repository containers 850 for individual 
offer types 852. Entries in the NDS hierarchy can be added, 
deleted, modified, moved via drag-n-drop operations and 
standard NDS ADMin interfaces. NDS liceasing informa- 
tion can additionally be associated with the components. 
Component Replication 

The CMS of the present invention also advantageously 
utilizes component replication features. In the preferred 
embodiment, NDS replication may be utilized to enhance 
the distribution of CMS objects. For instance, an NDS tree 
with three replicated partitions an exemplary company XYZ 
includes partition for New York (9A), Dallas (9B), and LA 
(9C). As objects are added to and deleted from individual 
partitions, NDS loosely replicates the information through- 
out the entire company XYZ. If a new service implemen- 
tation is added to the component server in the New York 9A 
partition for example, this service is replicated transparently 
across the company to the other partitions in Dallas 9B and 
LA 9C by NDS replication. As a result, a distribution 
mechanism for administrators is realized. 

The foregoing description has been directed to specific 
embodiments of this invention. It will be apparent, however, 
that other variations and modifications may be made to the 
described embodiments, with the attainment of some or all 
of their advantages. Therefore, it is the object of the 
appended claims to cover all such variations and modifica- 
tions as come within the true spirit and scope of the 
invention. 

What is claimed is: 

1. A component server for integrating, exposing and 
managing distributed components residing on a computer 
network, comprising: 

a component management service for controlling requests 

for distributed components and services; and 
a component registry for accessing registered components 
and services in response to requests from said compo- 
nent management service, said component registry 
including, 

a description repository for performing an initial look 

up function based on the type of the request, 
an offer repository for receiving the request when the 
component type is located in said description reposi- 
tory and having instances of components stored 
therein, an instance of said components being 
accessed when the instance matches the request, 
an object factory repository having implementations of 
the components registered in said offer repository 
stored therein, an implementation being invoked 
corresponding to the component instance accessed 
by said offer repository, and 
an interface adapter repository for storing interface 
specifications for the implementations stored in said 
object factory repository, an interface specification 
being passed to said component management service 
for the invoked implementation; 
said component management service providing the nec- 
essary binding between the requested and offered com- 
ponents. 
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2. A component server according to claim 1, wherein said 
component management service comprises software for 
managing the components and services across a plurality of 
object models, hardware devices, network devices and types 
of information. 

3. A component server according to claim 1, wherein said 
component registry comprises information for registered 
components and services so that said component manage- 
ment service may globally register, discover and bind 
offered components and services to requested components 
and services which are registered in said component registry. 

4. A component server according to claim 1, wherein said 
component management service further controls authenti- 
cated access for registering, discovering and binding of 
offered components and services. 

5. A component server according to claim 1, wherein said 
component management service further provides a single 
point of control for managing hardware and embedded 
devices that discovers and binds requested components and 
services based on security access controls. 

6. A component server according to claim 1, wherein said 
component management service further provides a single 
point of control for managing information that discovers and 
binds requested components and services based on security 
access controls. 

7. A component server according to claim 1, wherein said 
component management service further provides a single 
point of control for distributing components and services. 

8. A component server according to claim 1, wherein said 
component management service further provides a single 
point of control for licensing components and services. 

9. A component server according to claim 1, wherein said 
component management service further provides a single 
point of control for re-direcling requested components and 
services. 

10. A component server according to claim 1, wherein 
said component management service further provides a 
single point of control for bridging object models of 
requested components and services. 

11. A component server according to claim 1, wherein the 
component registry and the component management service 
operate with CORBA, COM and Java RMI standards for 
component infrastructures. 

12. A component server according to claim 1, wherein the 
framework for said component registry is based upon Net- 
Ware Directory Services (^fDS). 

13. A component server according to claim 12, wherein 
NDS provides authentication, replication, distribution, and 
management for the offered and requested components. 

14. A component server according to claim 12, wherein 
NDS provides a persistent storage and security access con- 
trol for said component registry. 

15. A component server according to claim 1, wherein the 
framework for said component registry is based upon LDAP, 
flat file, or ODBC/JDBC databases, 

16. A component server according to claim 1, wherein 
said component management service comprises an interface 
adapter for transforming the offered component to interface 
with the requested component. 

17. A component server according to claim 1, wherein 
said component registry functions as a central repository for 
caching of components and services to local registries for 
the requested components and services. 

18. A component server according to claim 17, wherein 
said central repository permits mobile computing by the 
requested components and services. 

19. A component server according to claim 1, wherein 
said component management service performs load balanc- 
ing for the requested components and services. 
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20. A system for integrating, exposing and managing 
distributed components residing on a computer network, 
comprising: 

managing means for controlling requests for distributed 

components; and 
registry means for accessing registered components in 

response to requests from said managing means, said 

registry means including, 

first means for performing an initial look up function 
based on the type of the request, 

second means for receiving the request when the com- 
ponent type is located in said first means and having 
instances of components stored therein, an instance 
of said components being accessed when the 
instance matches the request, 

third means having implementations of the components 
registered in said second means stored therein, an 
implementation being invoked corresponding to the 
component instance accessed by said second means, 
and 

fourth means for storing interface specifications for the 
implementations stored in said third means, an inter- 
face specification being passed to said managing 
means for the invoked implementation; 
said managing means providing the necessary binding 
between the requested and offered components. 

21. A system according to claim 20, wherein said man- 
aging means comprises software for managing the compo- 
nents across a plurality of object models, hardware devices, 
network devices and types of information. 

22. A system according to claim 20, wherein said registry 
means comprises information for registered components so 
that said managing means may globally register, discover 
and bind offered components to requested components 
which are registered in said registry means. 

23. A system according to claim 20, wherein said man- 
aging means further controls authenticated access for 
registering, discovering and binding of offered components. 

24. A system according to claim 20, wherein the frame- 
work for said registry means is based upon NetWare Direc- 
tory Services (NDS). 

25. A system according to claim 20, wherein said man- 
aging means comprises adapting means for transforming the 
offered component to interface with the requested compo- 
nent. 

26. A method for integrating, exposing and managing 
distributed components residing on a computer network, 
comprising the steps of: 

(a) controlling requests for distributed components; 

(b) accessing registered components in response to 
requests from said step (a), said step (b) including the 
steps of, 

(i) performing an initial look up function based on the 
type of the request, 

(ii) receiving the request when the component type is 
located at said step (i) and having instances of 
components stored therein, an instance of said com- 
ponents being accessed when the instance matches 
the request, 

(iii) invoking a registered implementation correspond- 
ing to the component instance accessed at said step 
(ii), and 

(iv) sUjring interface specifications for the registered 
implementations, an interface specification being 
passed to said step (a) for the invoked implementa- 
tion; and 
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(c) providing the necessary binding between the requested 
and offered components. 

27. A method according to claim 26, wherein said step (a) 
comprises the step of controlling authenticated access for 
registering, discovering and binding of offered components. ^ 

28. A method according to claim 26, wherein said step (a) 
comprises the step of transforming the offered component to 
interface with the requested component. 

29. A computer readable mediimi containing executable 
program instructions for integrating, exposing and managing 
disUibuted components rcsiddng on a computer network, the 10 
executable program instructions comprising the program 
instructions for: 

(a) controlling requests for distributed components; 

(b) accessing registered components in response to 
requests from said step (a), said step (b) including the ^5 
steps of, 

(i) performing an initial look up fiinction based on the 
type of the request; 

(ii) receiving the request when the component type is 
located at said step (i) and having instances of 
components stored therein, an instance of said com- 
ponents being accessed when the instance matches 
the request; 
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(iii) invoking a registered implementation correspond- 
ing to the component instance accessed at said step 
(ii), and 

(iv) storing interface specifications for the registered 
implementations, an interface specification being 
passed to said step (a) for the invoked implementa- 
tion; and 

(c) providing the necessary binding between the requested 
and offered components. 

30. A computer readable medium according to claim 29, 
wherein said step (a) comprises the program instruction for 
controlling authenticated access for registering, discovering 
and binding of offered components. 

31. A computer readable medium according to claim 29, 
wherein said step (a) comprises program instruction for 
transforming the offered component to interface with the 

^ requested component. 
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